Cet outil permet de vérifier la validité d’un échange de données d’urbanisme CNIG.

Il génère dans son fichier de log, un rapport présentant les erreurs ou avertissement concernant cet échange.

Dans certains cas, des fichiers d’échanges récupérés du Géoportail de l’urbanisme et ayant été validés par le vérificateur du Géoportail, sont rejetés par PCIBase lors de l’intégration. PCIBase ne fait pas les mêmes vérifications que le Géoportail.

Par exemple, PCIBase ne vérifie pas les métadonnées, mais il vérifie que le contenu des données, dans les échanges CNIG, soit strictement conforme aux standards définis par le CNIG, c’est pourquoi des données d’urbanisme acceptées par le Géoportail, peuvent être refusées par PCIBase.

!          Cette vérification se fait uniquement sur les données nécessaires à la cohérence du modèle de données FONCIER et au fonctionnement des applications arcOpole PRO.

Exemple :

Si dans la définition d’un champ CNIG, pour une date, il est indiqué que 8 caractères sont attendus, le vérificateur Géoportail vérifiera que la définition du champ est bien de 8 caractères mais ne vérifie pas le contenu de ce champ.  PCIBase vérifie, en plus, que la donnée contenue dans ce champ est bien de 8 caractères, conformément aux règles de codifications de la norme.

Extrait de la documentation « Standard CNIG PLU v2017d », paragraphe 4.3, Règles d'organisation et de codification :

Dans le log d’intégration de PCIBase, si le contenu du champ n’est pas conforme, il y aura une remarque non bloquante si c’est un champ considéré comme « informatif » (exemple : « URLFIC » dans la table ZONE_URBA) ou bien une erreur bloquante si c’est un champ considéré comme « fonctionnel » (exemple : « DATAPPRO » dans la table DOC_URBA).

Cf. 6.4, Vérifications d’un échange de données d’urbanisme CNIG avant intégration, pour les principales erreurs qui peuvent être rencontrées à l’intégration des documents d’urbanisme.

Outil : Urbanisme/Intégration/Intégration des données d’urbanisme CNIG

 

Ligne de commande : VERIFICATION_URBA

►     Dossier « donnees_geographiques » des données CNIG :

Sous-dossier « donnees_geographiques » du dossier de l’échange CNIG des données à intégrer. Ce dossier doit contenir (entre autres) des fichiers shape (*.shp).

Pour les DU (PLU/PLUi, CC, PSMV), son dossier parent doit contenir des tables dBase (*DOC_URBA*.dbf et *DOC_URBA_COM*.dbf).

En mode outil, si la référence spatiale des données ne peut pas être déterminée dès la sélection du dossier, un avertissement le signalera, mais cela n’empêche pas d’exécuter l’outil.

►     Référence spatiale :

-   En mode outil, ce paramètre est déterminé automatiquement (si c’est possible) et désactivé. Il est juste présent pour information.

-   En mode ligne de commande, ce paramètre n’existe pas.

►     Type de données d’urbanisme :

-   En mode outil, ce paramètre est déterminé automatiquement et désactivé. Il est juste présent pour information.

-   En mode ligne de commande, ce paramètre n’existe pas.

Pour plus d’informations, cf. 6.4.1, Récupération du type et de la version du dossier d’un échange CNIG.

►     Version des données d’urbanisme :

-   En mode outil, ce paramètre est déterminé automatiquement et désactivé. Il est juste présent pour information.

-   En mode ligne de commande, ce paramètre n’existe pas.

Le type et la version des données CNIG sont déterminés à partir des données.

Pour les SUP v2016, le code emprise est déterminé à partir du nom du dossier des données CNIG.

S'il respecte la nomenclature de nommage <idGest>_<catégorie>_<maillage>_<date>, le code emprise sera <maillage>.

Le type et la version des données sont affichés, ainsi que les éventuels avertissements ou erreurs détectées dans les données CNIG.

Des fichiers de log sont créés, contenant les messages générés pendant le traitement.

Le nom de ces fichiers de log est indiqué en début et fin de traitement, et correspond à la date de lancement du traitement.